An event is simply an action or an occurrence detected by a program, and event processing involves determining what to do in response to the detection. Event processing arrangements often employ finite state machines (FSMs) to keep track of detected events and their effect.
Known event-processing arrangements define which events must be detected, and rules for processing them, in software executables or libraries. For example, the Java Finite State Machine Framework provides extensible actions for FSM transitions, which are fixed in code. Therefore, changes to the event-processing rules or to the sets of events to be detected require software developers to make the changes by modifying the event-processing code and delivering a new version of the entire event-processing system. The time, effort, and expertise that are involved in making these changes can be significant. But no way is provided to extend the FSM without code changes. Workflow-event-processing systems may use data files to describe event flows. But they, too, lack extensibility without reprogramming, and further lack ability to associate computations with event transitions. Also known are implementations of FSMs where the set of states and state transitions are described in XML or other-format data files. But these implementations have no computational ability on state transitions, and so cannot be employed to express event-processing rules. And, while some of these implementations may allow actions to be associated with FSM states, they provide only a fixed set of actions that are defined as a part of the FSM code, and thus are not extensible without reprogramming of the FSM. The use of plug-ins for handling elements of XML documents is also known. They are generally used to extend the capabilities of browsers, but the use of plug-ins driven by XML tags is also known in event publish/subscribe contexts. But changing or adding of new processing rules, even if the rules are implemented as plug-ins, requires delivery of new system software.